Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

The Unload statement does not execute the form’s Terminate event handler because the form is not actually destroyed until its last reference goes out of scope or is set to Nothing.

The following code is similar to the previous code, but it displays the value of the txtName control before it unloads the form. Visual Basic does not reload the form so the TextBox is not reset to its original value. The routine then sets the reference to the form to Nothing. At that point, the form’s Terminate event handler executes and the form is removed from memory. When the main form unloads, all forms are unloaded, so the program stops.

Private EmpFrm As EmployeeForm
    :
Private Sub ShowEmployeeForm()
    ‘ Create the form.
    Set EmpFrm = New EmployeeForm

    ‘ Display the form.
    EmpFrm.Show vbModal

    ‘ Display the txtName value.

    MsgBox EmpFrm.txtName.Text

    ‘ Unload the form.
    Unload EmpFrm

    ‘ Set the only reference to the for to Nothing.
    ‘ This executes the form’s Terminate event handler
    ‘ and removes the form from memory.
    Set EmpFrm = Nothing
End Sub

Always clear unused variables. Set forms and other objects to Nothing to ensure that the objects are actually destroyed.

Use Else Statements

Always use Else clauses in long If Then statements and Select statements. If the program should take specific action when the Else case occurs, put the appropriate code here. If the Else case should never arise, make the program stop so you can determine what caused the unexpected condition.

If condition1 Then
    :
ElseIf condition2 Then
    :
Else
    ‘ This should never happen.

    Stop
End If

This is similar to the technique described earlier for catching errors that can occur when you create a new constant or enumerated value. If the program changes so the If Then or Select statement does something you did not anticipate, the Else clause will let you know so you can find and repair the problem.

Verify Results

An application should automatically verify important results. If the results are incorrect, it should stop so you can fix the problem.

Automatic verification can test a routine extremely thoroughly. For instance, a program might use a network shortest-path calculation to assign employees to jobs. During the development and testing of the program, the shortest-path algorithm may be executed thousands of times. If the algorithm verifies its results each time, it will test itself thoroughly under normal circumstances.

Sometimes you can write a routine to verify the results directly. For instance, to verify that a sorting routine correctly sorted a list, you can simply compare each item to the one before it in the list as in the following code:

‘ Verify the list is sorted.

Private Sub VerifySort(values() As Long)
Dim i As Integer

    ‘ Verify that each item is at least as large
    ‘ as the previous item.
    For i = LBound(Values) + 1 To UBound(Values)
        If Values(i - 1) > Values(i) Then Stop
    Next i
End Sub

Another method for verifying important results is to use two different routines and then compare their results. If they agree, the result is probably correct. If they disagree, you definitely have a bug in one or both of the routines.

If the two methods are too slow to keep both in the finished program, use conditional compilation directives to remove the slower routine from the final code.

Be certain that the two methods are significantly different. If they use the same techniques, they may both contain the same bugs. For example, because quicksort and heapsort are two very different sorting routines, they are unlikely to contain the same bug.

Even two completely different routines may have shared problems based on invalid assumptions. For example, suppose you write quicksort and heapsort routines to validate each other. You might assume that the list of numbers to be sorted is stored in an array with lower bound 1. The application may actually store values in an array with lower bound of 0. Because you made the same incorrect assumption in both routines, they verify each other even though they are both wrong.

If you remember to make the routines thoroughly verify their assumptions and parameter values, this particular bug is not a problem. When the program first tries to sort a 0-based array, it will see that the array violates its assumptions and it will stop.

You can also reduce the likelihood of making incorrect assumptions by having two different programmers write the two routines. Each may make bad assumptions, but hopefully they will make different bad assumptions and their results will disagree.

Self-Test

Program Bad5, shown in Figure 5.3, violates several of the guidelines described in this chapter. The program randomly generates 50 values in increasing order. Enter a target value and select a search method. Then click the Search button and the program will use the method you selected to find the target. It displays the position of the target in the list and the number of steps it performed during the search. You will find that the binary search uses far fewer steps that the linear search.

Figure 5.3  Program Bad5 searches for a target value using one of two algorithms.